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Status of this Memo 


This document specifies an Internet standards track protocol for the 
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Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


The Layer Two Tunneling Protocol (L2TP) provides a standard method 
for transporting the link layer of the Point-to-Point Protocol (PPP) 
between a dial-up server and a Network Access Server, using a network 
connection in lieu of a physical point-to-point connection. This 
document describes the use of an Asynchronous Transfer Mode (ATM) 
network for the underlying network connection. ATM User-Network 
Interface (UNI) Signaling Specification Version 4.0 or Version 3.1 
with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to the 
ATM network. 


Applicability 
This specification is intended for implementations of L2TP that use 


ATM to provide the communications link between the L2TP Access 
Concentrator and the L2TP Network Server. 
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Le 


Introduction 


The Point-to-Point Protocol (PPP) [RFC1661], is frequently used on 
the link between a personal computer with a dial modem and a network 
service provider, or NSP. The Layer Two Tunneling Protocol (L2TP) 
[RFC2661] enables a dial-up server to provide access to a remote NSP 
by extending the PPP connection through a tunnel in a network to 
which both it and the NSP are directly connected. A "tunnel" is a 
network layer connection between two nodes, used in the role of a 
data link layer connection between those nodes, possibly as part of a 
different network. In [RFC2661] the dial-up server is called an L2TP 
Access Concentrator, or LAC. The remote device that provides access 
to a network is called an L2TP Network Server, or LNS. L2TP uses a 
packet delivery service to create a tunnel between the LAC and the 
LNS. "L2TP is designed to be largely insulated from the details of 
the media over which the tunnel is established; L2TP requires only 
that the tunnel media provide packet oriented point-to-point 
connectivity" [RFC2661]. An ATM network with AAL5 offers a suitable 
form of packet oriented connection. This standard supplements 
[RFC2661] by providing details specific to the use of AAL5 for a 
point-to-point connection between LAC and LNS. 


Conventions 


Requirements keywords The key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


A list of acronyms used in this document is given at the end of the 
document as Appendix A. 


AAL5 Layer Service Interface 


L2TP treats the underlying ATM AAL5 layer service as a bit- 
synchronous point-to-point link. In this context, the L2TP link 
corresponds to an ATM AAL5 virtual circuit (VC). The VC MUST be 
full-duplex, point to point, and it MAY be either dedicated (i.e., 
permanent, set up by provisioning) or switched (set up on demand.) 


The AAL5 message mode service, in the non-assured mode of operation, 
without the corrupted delivery option MUST be used. 


Interface Format - The L2TP/AAL5 layer boundary presents an octet 
service interface to the AAL5 layer. There is no provision for sub- 
octets to be supplied or accepted. 
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3.1 Maximum Transfer Unit 


Each L2TP PDU MUST be transported within a single AAL5 PDU. 
Therefore the maximum transfer unit (MTU) of the AAL5 connection 
constrains the MTU of the L2TP tunnel that uses the connection and 
the MTU of all PPP connections that use the tunnel. ([RFC1661] 
refers to this as Maximum Receive Unit, or MRU. In [SIG31], it is 
the Forward and Backward Maximum CPCS-SDU Size.) 


An implementation MUST support a PPP MRU of at least 1500 bytes. 


An implementation SHOULD use a larger MTU than the minimum value 
specified above. It is RECOMMENDED that an implementation support an 
IP packet of at least 9180 bytes in the PPP PDU. 


3.2 Quality of Service 


In order to provide a desired Quality of Service (Q0S), and possibly 
different qualities of service to different client connections, an 
implementation MAY use more than one AAL5 connection between LAC and 
LNS. 


QoS mechanisms, such as Differentiated UBR [DUBR], that could involve 
inverse multiplexing a tunnel across multiple VCs are for further 
study. QoS mechanisms applicable to a single tunnel corresponding to 
a single VC, are independent of the ATM transport and out of scope of 
this document. 


3.3 ATM Connection Parameters 


The L2TP layer does not impose any restrictions regarding 
transmission rate or the underlying ATM layer traffic descriptor 
parameters. 


Specific traffic parameters MAY be set for a PVC connection by 
agreement between the communicating parties. The caller MAY request 
specific traffic parameters at the time an SVC connection is set up. 


Autoconfiguration of end-systems for PVCs can be facilitated by the 
use of the optional ILMI 4.0 extensions documented in [ILMIA]. This 
provides comparable information to the IEs used for control plane 
connection establishment. 
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4. 


Multi-Protocol Encapsulation 


This specification uses the principles, terminology, and frame 
structure described in "Multiprotocol Encapsulation over ATM 
Adaptation Layer 5" [RFC2684]. The purpose of this specification is 
not to reiterate what is already standardized in [RFC2684], but to 
specify how the mechanisms described in [RFC2684] are to be used to 
map L2TP onto an AAL5-based ATM network. 


As specified in [RFC2684], L2TP PDUs shall be carried in the payload 
field of Common Part Convergence Sublayer (CPCS) PDUs of AAL5, and 
the Service Specific Convergence Sublayer (SSCS) of AAL5 shall be 
empty. 


Section 1 of [RFC2684] defines two mechanisms for identifying the 
protocol encapsulated in the AAL5 PDU’s payload field: 


1. Virtual circuit (VC) based multiplexing. 
2. Logical Link Control (LLC) encapsulation. 


In the first mechanism, the payload’s protocol type is implicitly 
agreed to by the end points for each virtual circuit using 
provisioning or control plane procedures. This mechanism will be 
referred to as "VC-multiplexed L2TP". 


In the second mechanism, the payload’s protocol type is explicitly 
identified in each AAL5 PDU by an IEEE 802.2 LLC header. This 
mechanism will be referred to as "LLC encapsulated L2TP". 


An L2TP implementation: 


1. MUST support LLC encapsulated L2TP on PVCs. 
2. MAY support LLC encapsulated L2TP on SVCs. 
3. MAY support VC-multiplexed L2TP on PVCs or SVCs. 


When a PVC is used, the endpoints must be configured to use one of 
the two encapsulation methods. 


If an implementation supports SVCs, it MUST use the [Q.2931] Annex C 
procedure to negotiate connection setup, encoding the Broadband Lower 
Layer Interface (B-LLI) information element (IE) to signal either 
VC-multiplexed L2TP or LLC encapsulated L2TP. The details of this 
control plane procedure are described in section 7. 


If an implementation is connecting through a Frame Relay/ATM FRF.8 
[FRF8] service inter-working unit, then it MUST use LLC encapsulated 
L2TP. 
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5. LLC Encapsulated L2TP over AAL5 


When LLC encapsulation is used, the payload field of the AAL5 CPCS 
PDU SHALL be encoded as shown in Figure 1. The pertinent fields in 
that diagram are: 


1. IEEE 802.2 LLC header: Source and destination SAP of OxAA 
followed by a frame type of Un-numbered Information (value 
0x03). This LLC header indicates that an IEEE 802.1la SNAP 
header follows [RFC2684]. 


2. IEEE 802.1a SNAP Header: The three octet Organizationally 
Unique Identifier (OUI) value of 0x00-00-5E identifies IANA 
(Internet Assigned Numbers Authority.) The two octets Protocol 
Identifier (PID) identifies L2TP as the encapsulated protocol. 
The PID value is 0x0007. 


3. The L2TP PDU: 


Figure 1 - LLC Encapsulated L2TP PDU 


4------------------------- + -------- 
| Destination SAP (0xAA) | a 
+------------------------- + | 
| Source SAP (OxAA) | LLC header 
+------------------------- + | 
| Frame Type = UI (0x03) | V 
4------------------------- + -------- 
| OUI (0x00-00-5E) | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header 
| PID (0x00-07) | | 
4------------------------- + -------- 
| | | 
L2TP PDU 

| 

4------------------------- + -------- 


Note: The format of the overall AAL5 CPCS PDU is shown in the next 
section. 


The end points MAY be bi-laterally provisioned to send other LLC- 


encapsulated protocols besides L2TP across the same virtual 
connection. 
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6. Virtual Circuit Multiplexed L2TP over AAL5 


vc-multiplexed L2TP over AAL5 is an alternative technique to LLC 
encapsulated L2TP over AAL5. In this case, the L2TP PDU is the AAL5 
payload without an LLC header. This is sometimes called "Null 
encapsulation." 


Figure 2 - AAL5 CPCS-PDU Format 


4------------------------------- + ------- 
| | i 

| ; | | 

| CPCS-PDU payload | L2TP PDU 

| up to 2%16 - 1 octets) | 

| Ih = PM 
4------------------------------- + ------- 

| PAD ( 0 - 47 octets) | 
4------------------------------- + ------- 

| CPCS-UU (1 octet ) | A 
+------------------------------- + | 

| CPI (1 octet ) | | 

A E +CPCS-PDU Trailer 
| Length (2 octets) | | 

+ eS E ee ee ee ee See ee ee 

| CRC (4 octets) | vV 
4------------------------------- + ------- 


The Common Part Convergence Sub-layer (CPCS) PDU payload field 
contains user information up to 2%16 - 1 octets. 


The PAD field pads the CPCS-PDU to fit exactly into the ATM cells 
such that the last 48 octet cell payload created by the SAR sublayer 
will have the CPCS-PDU Trailer right justified in the cell. 


The CPCS-UU (User-to-User indication) field is used to transparently 
transfer CPCS user to user information. The field has no function 
under the multi-protocol ATM encapsulation and MAY be set to any 
value. 


The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 
64 bits. Possible additional functions are for further study in 
ITU-T. When only the 64 bit alignment function is used, this field 
SHALL be coded as 0x00. 


The Length field indicates the length, in octets, of the payload 


field. The maximum value for the Length field is 65535 octets. A 
Length field coded as 0x00 MAY be used for the abort function. 
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The CRC field is computed over the entire CPCS-PDU except the CRC 
field itself. 


The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in 
[RFC2661]. 


7. Out-of-Band Control Plane Signaling 
7.1 Connection Setup 


An SVC connection can originate at either the LAC or the LNS. An 
implementation that supports the use of SVCs MUST be able to both 
originate and respond to SVC setup requests. Except for the B-LLI IE 
specified below, all other IEs required for ATM User-Network 
Interface (UNI) Signaling Specification Version 4.0 [SIG40] should be 
encoded as per [RFC2331]. 


When originating an SVC AAL5 connection, the caller MUST request in 
the SETUP message either VC-multiplexed L2TP, LLC encapsulated L2TP, 
or both vC-multiplexed and LLC-encapsulated L2TP. The B-LLI IE SHALL 
be used to specify the requested encapsulation method. When a caller 
is offering both encapsulations, the two B-LLI IEs SHALL be encoded 
within a Broadband Repeat Indicator information element in the order 
of the sender’s preference. 


An implementation MUST be able to accept an incoming call that offers 
LLC encapsulated L2TP in the caller’s request. The called peer’s 
implementation MUST reject a call setup request that only offers an 
encapsulation that it does not support. Implementations originating 
a call offering both protocol encapsulation techniques MUST be able 
to accept the use of either encapsulation techniques. 


When originating an LLC encapsulated call that is to carry an L2TP 
payload, the [0.2931] B-LLI IE user information layer 2 protocol 
field SHALL be encoded to select LAN Logical Link Control 
(ISO/IEC8802-2) in octet 6. See [RFC2331] Appendix A for an example. 


When originating a VC-multiplexed call that is to carry an L2TP 
payload, the [0.2931] B-LLI IE user information layer 2 protocol 
field SHALL be encoded to select no layer 2 protocol in octet 6 and 
layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577 
[ISO9577] in octet 7. Furthermore, as per DSL Forum TR-037 
[DSLF037], the extension octets specify VC-multiplexed L2TP by using 
the SNAP IPI, followed by an OUI owned by IANA, followed by the PID 
assigned by IANA for L2TP. Thus, the User Information layer 3 
protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's 
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payload field will always contain an L2TP PDU. The SNAP IPI is 
employed only to use the IANA L2TP protocol value to specify the VC- 
multiplexed PDU. 


If the caller offers both encapsulation methods and the called peer 
accepts the call, the called peer SHALL specify the encapsulation 
method by including exactly one B-LLI IE in the Connect message. 


If an SVC tunnel is reset in accordance with section 4.1 of 
[RFC2661], both ends MUST clear the SVC. Any user sessions on the 
tunnel will be terminated by the reset. Either end MAY attempt to 
re-establish the tunnel upon receipt of a new request from a client. 


7.2 Connection Setup Failure 


When a connection setup fails, the L2TP entity that attempted the 
connection setup MAY consider the called entity unreachable until 
notified that the unreachable entity is available. The conditions 
under which an entity determines that another is unreachable and how 
it determines that the other is available again are implementation 
decisions. 


7.3 Connection Teardown 


When there are no active sessions on an SVC tunnel, either end MAY 
optionally clear the connection. 


8. Connection Failure 


Upon notification that an AAL5 SVC connection has been cleared, an 
Implementation SHALL tear down the tunnel and return the control 
connection to the idle state. 


9. Security Considerations 


The Layer Two Tunneling Protocol base specification [RFC2661] 
discusses basic security issues regarding L2TP tunneling. It is 
possible that the L2TP over AAL5 tunnel security may be compromised 
by the attack of ATM transport network itself. The ATM Forum has 
published a security framework [AFSEC1] and a security specification 
[AFSEC2] that define procedures to guard against common threats to an 
ATM transport network. Applications that require protection against 
threats to an ATM switching network are encouraged to use 
authentication headers, or encrypted payloads, and/or the ATM-layer 
security services described in [AFSEC2]. 
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Appendix A. Acronyms 
AALS ATM Adaptation Layer Type 5 
ATM Asynchronous Transfer Mode 


B-LLI Broadband Low Layer Information 


CPCS Common Part Convergence Sublayer 
TANA Internet Assigned Numbers Authority 
IE Information Element 

L2TP Layer Two Tunneling Protocol 

LAC L2TP Access Concentrator 

LLC Logical Link Control 

LNS L2TP Network Server 

MTU Maximum Transfer Unit 

MRU Maximum Receive Unit 

NSP Network Service Provider 

OUI Organizationally Unique Identifier 
PDU Protocol Data Unit 

PID Protocol Identifier 

PPP Point-to-Point Protocol 

PVC Permanent Virtual Circuit 

SAP Service Access Point 

SNAP Subnetwork Address Protocol 

SVC Switched Virtual Circuit 

VC Virtual Circuit 
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Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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